Selective resource migration

ABSTRACT

Selective resource migration is disclosed. A computer system includes physical memory and a plurality of physical processors. Each of the processors has one or more cores and each core instantiates one or more virtual processors that executes program code. Each core is configured to invoke a hyper-kernel on its hosting physical processor when the core cannot access a portion of the physical memory needed by the core. The hyper-kernel selectively moves the needed memory closer to a location accessible by the physical processor or remaps the virtual processor to another core.

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 15/429,638 entitled SELECTIVE RESOURCE MIGRATION filed Feb. 10,2017, which is incorporated herein by reference for all purposes, whichis a continuation of U.S. patent application Ser. No. 14/880,132entitled RESOURCE REQUEST AND TRANSFER IN A MULTI-NODE DISTRIBUTEDSYSTEM filed Oct. 9, 2015, now U.S. Pat. No. 9,609,048, which isincorporated herein by reference for all purposes, which is acontinuation of U.S. patent application Ser. No. 13/830,094, entitledSELECTIVE DATA MIGRATION OR REMAPPING OF VIRTUAL PROCESSORS TO PROVIDEREQUIRED DATA ACCESSIBILITY TO PROCESSOR CORES filed Mar. 14, 2013, nowU.S. Pat. No. 9,191,435, which is incorporated herein by reference forall purposes, which claims priority to U.S. Provisional PatentApplication No. 61/692,648 entitled HIERARCHICAL DYNAMIC SCHEDULINGfiled Aug. 23, 2012 which is incorporated herein by reference for allpurposes.

BACKGROUND OF THE INVENTION

Software applications are increasingly operating on large sets of dataand themselves becoming increasingly complex. In some cases, distributedcomputing systems are used to support such applications (e.g., where alarge database system distributes portions of data onto a landscape ofdifferent server nodes, and optimizes queries into sub-queries that getdistributed across that landscape). Unfortunately, significant efforthas to be spent managing that distribution both in terms of dataplacement and data access distribution methods, including thecomplexities of networking. If the landscape changes, if the dataorganization changes, or if the workload changes, significant work willbe required. More generally, the behavior of complex computing systemschanges over time, e.g., with new releases of applications, the additionof new intermediate software layers, new operating system releases, newprocessor models, and changing structural characteristics of data,increasing amounts of data, and different data access patterns.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 illustrates an embodiment of a computer system.

FIG. 2 illustrates the physical structure of the computer system as ahierarchy.

FIG. 3A depicts a virtualized computing environment in which multiplevirtual machines (with respective multiple guest operating systems) runon a single physical machine.

FIG. 3B depicts a virtualized computing environment in which multiplephysical machines collectively run a single virtual operating system.

FIG. 4A depicts an example of a software stack.

FIG. 4B depicts an example of a software stack.

FIG. 5 depicts an example of an operating system's view of hardware onan example system.

FIG. 6A depicts an example of a hyperthread's view of hardware on asingle node.

FIG. 6B depicts an example of a hyper-kernel's view of hardware on anexample system.

FIG. 7 depicts an example of an operating system's view of hardware onan example of an enterprise supercomputer system.

FIG. 8 illustrates an embodiment of a process for selectively migratingresources.

FIG. 9 illustrates an embodiment of a process for performinghierarchical dynamic scheduling.

FIG. 10 illustrates an example of an initial memory assignment andprocessor assignment.

FIG. 11 illustrates an updated view of the memory assignment and anunchanged view of the processor assignment.

FIG. 12 illustrates a memory assignment and an updated view of theprocessor assignment.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

FIG. 1 illustrates an embodiment of a computer system. System 100 isalso referred to herein as an “enterprise supercomputer” and a“mainframe.” In the example shown, system 100 includes a plurality ofnodes (e.g., nodes 102-108) located in close proximity (e.g., locatedwithin the same rack). In other embodiments, multiple racks of nodes(e.g., located within the same facility) can be used in the system.Further, the techniques described herein can also be used in conjunctionwith distributed systems.

The nodes are interconnected with a high-speed interconnect (110) suchas 10-gigabit Ethernet, direct PCI-to-PCI, and/or InfiniBand. Each nodecomprises commodity server-class hardware components (e.g., a blade in arack with its attached or contained peripherals). In the example shownin FIG. 1, each node includes multiple physical processor chips. Eachphysical processor chip (also referred to as a “socket”) includesmultiple cores, and each core has multiple hyperthreads.

As illustrated in FIG. 2, the physical structure of system 100 forms ahierarchy (from the bottom) of hyperthreads (230), cores (210-224),physical processor chips (202-208), and nodes (102-108 (with nodes 104,106, etc. omitted from the figure and represented as ellipses)). Thetree depicted in FIG. 2 is of a fixed size, defined by the hardwareconfiguration.

As will be described in more detail below, each enterprise supercomputer(e.g., system 100) runs a single instance of an operating system. Boththe operating system, and any applications, can be standard commerciallyavailable software and can run on system 100. In the examples describedherein, the operating system is Linux, however other operating systemscan also be used, such as Microsoft Windows, Mac OS X, or FreeBSD.

In a traditional virtualized computing environment, multiple virtualmachines may run on a single physical machine. This scenario is depictedin FIG. 3A. In particular, three virtual machines (302-306) are runningthree guest operating systems on a single physical machine (308), whichhas its own host operating system. In contrast, using the techniquesdescribed herein, multiple physical machines (354-358) collectively runa single virtual operating system (352), as depicted in FIG. 3B.

One example of a software stack is depicted in FIG. 4A. Such a stack maytypically be used in traditional computing environments. In the stackshown in FIG. 4A, an application (402) sits above a database engine(404), which in turn sits upon an operating system (406), underneathwhich lies hardware (408). FIG. 4B depicts a software stack used in someembodiments. As with the stack shown in FIG. 4A, an application (452)sits above a database engine (454), which in turn sits upon an operatingsystem (456). However, underneath the operating system and above thehardware is a layer of software (referred to herein as a hyper-kernel)that observes the system running in real time and optimizes the systemresources to match the needs of the system as it operates. Thehyper-kernel conceptually unifies the RAM, processors, and I/O (InputOutput resources for example Storage, Networking resources) of a set ofcommodity servers, and presents that unified set to the operatingsystem. Because of this abstraction, the operating system will have theview of a single large computer, containing an aggregated set ofprocessors, memory, and I/O. As will be described in more detail below,the hyper-kernel optimizes use of resources. The hyper-kernel can alsohelp optimize other I/O system resources such as networks and storage.In some embodiments, based on observations and profiles of runningsoftware, performance indicators (hints) are provided to upper layers(e.g., database management systems) about the dynamic performance of thesystem that can further improve overall system performance.

The hyper-kernel can be ported to all major microprocessors, memory,interconnect, persistent storage, and networking architectures. Further,as hardware technology evolves (e.g., with new processors, new memorytechnology, new interconnects, and so forth), the hyper-kernel can bemodified as needed to take advantage of industry evolution.

As shown in FIG. 4B, operating system 456 is running collectively acrossa series of nodes (458-462), each of which has a hyper-kernel running onserver hardware. Specifically, the operating system is running on avirtual environment that is defined by the collection of hyper-kernels.As will be described in more detail below, the view for operating system456 is that it is running on a single hardware platform that includesall of the hardware resources of the individual nodes 458-462. Thus, ifeach of the nodes includes 1 TB of RAM, the operating system will haveas a view that it is running on a hardware platform that includes 3 TBof RAM. Other resources, such as processing power, and I/O resources cansimilarly be collectively made available to the operating system's view.

FIG. 5 depicts an example of an operating system's view of hardware onan example system. Specifically, operating system (502) runs on top ofprocessors 504-508 and physical shared memory 510. As explained above,an operating system can run on either a traditional computing system oron an enterprise supercomputer such as is shown in FIG. 1. In eithercase, the view of the operating system will be that it has access toprocessors 504-508 and physical shared memory 510.

FIG. 6A depicts an example of a hyperthread's view of hardware on asingle node. In this example, a node has four hyperthreads denoted H1(602) through H4 (608). Each hyperthread can access all portions ofphysical shared memory 612. Physical shared memory 612 is linear,labeled location 0 through a maximum amount, “max.” The node alsoincludes three levels of cache (610).

FIG. 6B depicts an example of a hyper-kernel's view of hardware on anexample system. In this example, three nodes (652-656) are included inan enterprise supercomputer. Each of the three nodes has fourhyperthreads, a physical shared memory, and cache (i.e., each node is anembodiment of node 600 shown in FIG. 6A). A hyperthread on a given node(e.g., node 652) has a view that is the same as that shown in FIG. 6A.However, the hyper-kernel is aware of all of the resources on all of thenodes (i.e., the hyper-kernel sees twelve hyperthreads, and all of thephysical shared memory). In the example shown in FIG. 6B, a givenhyperthread (e.g., hyperthread 658, “H1-4”) is labeled with its nodenumber (e.g., “1”) followed by a hyperthread number (e.g., “4”).

FIG. 7 depicts an example of an operating system's view of hardware onan example of an enterprise supercomputer system. The operating systemsees a plurality of “virtualized processors” denoted in FIG. 7 as P1through Pmax (702). The virtualized processors correspond to the totalnumber of hyperthreads across all nodes included in the enterprisesupercomputer. Thus, using the example of FIG. 6B, if a total of twelvehyperthreads are present across three nodes, a total of twelvevirtualized processors would be visible to an operating system runningon the enterprise supercomputer. The operating system also sees“virtualized physical memory” (704) that appears to be a large,physical, linear memory of a size equal to the total amount of physicalmemory across all nodes.

As will be described in more detail below, the hyper-kernel dynamicallyoptimizes the use of cache memory and virtual processor placement basedon its observations of the system as it is running. A “virtualprocessor” is a computing engine known to its guest operating system,i.e., one that has some operating system context or state. As will bedescribed in more detail below, a “shadow processor” is an anonymousvirtual processor, i.e., one that had been a virtual processor but hasnow given up its operating system context and has context known only tothe hyper-kernel.

Resource Virtualization

Memory Virtualization

As explained above, in the physical configuration, each node has anarray of memory addresses representing locations in memory. As such, ina physical configuration with three nodes (e.g., as depicted in FIG.6B), there are three memory locations each of which has address0x123456. In contrast, in the virtual configuration, all memoryaddresses are unique and represent the sum total of all memory containedin those three nodes. In the virtual configuration, all memory isshared, and all memory caches are coherent. In some embodiments, memoryis further subdivided into a series of contiguous blocks, withmonotonically increasing memory addresses. In the examples describedherein, each page has 4K bytes of memory, however, other subdivisionscan also be used, as applicable. The term“blocks” is used herein todescribe contiguous arrays of memory locations. In some embodiments, the“blocks” are “pages.”

Processor Virtualization

A virtual processor (e.g., virtual processor 706 of FIG. 7), as seen bythe operating system, is implemented on a hyperthread in the physicalconfiguration, but can be location independent. Thus, while theoperating system thinks it has 500 processors running on a singlephysical server, in actuality it might have 5 nodes of 100 processorseach. (Or, as is shown in FIG. 6B, the operating system will think ithas twelve processors running on a single physical server.) Thecomputation running on a virtual processor is described either by thephysical configuration on a hyperthread when the computation is running,or in a “continuation,” when the virtual processor is not running (i.e.,the state of an interrupted or stalled computation).

As used herein, a “continuation” represents the state of a virtualprocessor. Each continuation:

Has processor state (i.e., saved registers, etc.).

Has a set of performance indicators that guide a scheduler object withinformation about how to intelligently assign continuations to leafnodes for execution.

Has a virtual-processor identifier that indicates the processor theoperating system thinks is the physical processor to which thiscontinuation is assigned.

Has an event on which this continuation is waiting (possibly empty).

Has a state which includes: “waiting-for-event” or “ready.”

I/O Virtualization

I/O systems observe a similar paradigm to processors and memory. Deviceshave a physical address in the physical configuration and virtualaddresses in the virtual configuration. When migrating computations(described in more detail below), if for example, there are memorybuffers associated with I/O operations, the I/O devices used will likelyperform better if they are co-located with the memory with which theyare associated, and can be moved accordingly.

Resource Maps

Resource maps are used to translate between virtual and physicalconfigurations. The following are three types of resource maps used byenterprise supercomputers in various embodiments.

A “physical resource map” is a table that describes the physicalresources that are available on each node. It contains, for example, thenumber and type of the processors on each node, the devices, the memoryavailable and its range of physical addresses, etc. In some embodiments,this table is read-only and is fixed at boot time.

An “initial virtual resource map” is fixed prior to the booting of theoperating system and describes the virtual resources that are availablefrom the point of view of the operating system. The configuration isreadable by the operating system. In some cases, it may be desirable toconfigure a system (from the viewpoint of the operating system) thatdoes not match, one-to-one, with the underlying hardware resources. Asone example, it may be desirable for the operating system to have morememory and fewer cores. This can be accomplished by changing the ratioof memory to cores, i.e., by modifying the initial virtual resource map.

A “current resource map” is created and maintained by each hyper-kernelinstance. This map describes the current mapping between the virtualresource map and the physical resource map from the point of view ofeach node. For each entry in the virtual resource map, a definition ofthe physical resources currently assigned to the virtual resources ismaintained. Initially (e.g., at boot time), the current resource map isa copy of the initial virtual resource map. The hyper-kernel modifiesthe current resource map over time as it observes the characteristics ofthe resource load and dynamically changes the mapping of physicalresources to virtual resources (and vice-versa). For example, thedefinition of the location of the Ethernet controller eth27 in thevirtualized machine may at different times refer to different hardwarecontrollers. The current resource map is used by the hyper-kernel todynamically modify the virtual hardware resource mappings, such as thevirtual memory subsystem, as required.

Resource Migration Overview

Using the techniques described herein, virtualized resources can bemigrated between physical locations. As explained above, the operatingsystem is provided with information about the virtualized system, butthat information need not agree with the physical system.

In the following example, suppose an enterprise supercomputer holds alarge in-memory database, larger than can fit into a single node. Partof the database is in a first node, “node1.” Suppose one of the cores ona different node, “node2,” is trying to access data that is owned bynode1 and that does not reside locally in a cache on node2. The core onnode2 will receive a memory access violation because it is trying toaccess data that it believes it should be able to access (but cannot).As will be described in more detail below, the exception is handled inthe hyper-kernel.

One way that the situation can be resolved is by moving the needed areaof memory to node2, and then returning control back to the operatingsystem (which, in turn, returns it back to the database system). Thesoftware can then proceed as intended (i.e., as if the access violationnever occurred).

In many cases, there may be one or more other cores in other nodes(e.g., “node3”) that are also trying to access the same area block ofmemory as needed by node2 above. Node3 might be attempting to access thesame data, or it might be accessing different data contained in thememory that was moved (also referred to as “false sharing”). The datacould be moved to node3, but if the core on node2 asks for the data asecond time, the data would need to be moved back to node2 (i.e.,potentially moving the data back and forth repeatedly), which can beslow and wasteful. One way to avoid moving data back and forth betweencores is to recognize that both cores and the associated block of datashould be co-located. Using the techniques described herein, the memoryand the computation can be migrated so that they reside on the samenode. Doing so will result in a higher likelihood of faster access todata, and a higher probability of sharing data stored in local caches.

When the access violation occurs, an event is triggered (in a systemdependent way) to which the hyper-kernel responds. One example of howsuch an event can be handled is by the invocation of a panic routine.Other approaches can also be used, as applicable. As will be describedin more detail below, the hyper-kernel examines the cause of the eventand determines an appropriate strategy (e.g., low level transaction) forhandling the event. As explained above, one way to handle the event isfor one or more blocks of hyper-kernel virtualized memory to betransferred from one node's memory to another node's memory. Thetransfer would then be initiated and the corresponding resource mapswould be updated. A continuation would be built poised to be placed in alocal table in shared memory called the event table (discussed below) sothat the next thing the continuation does when it is resumed would be toreturn control to the operating system after the transfer is completed.A decision could also be made to move the virtual processor to the nodethat contains the memory being requested or to move the virtualizedmemory (and its virtualized memory address) from one node to another. Invarious embodiments, the hyper-kernel makes three decisions whenhandling an event: which (virtual) resources should move, when to movethem, and to where (in terms of physical locations) they should move.

TidalTree

The physical hierarchical structure depicted in FIG. 2 has an analogoussoftware hierarchy comprising a set of “scheduler objects” (i.e., datastructures), each of which has a set of characteristics described below.The scheduler objects form a “TidalTree,” which is an in-memory treedata structure in which each node of the tree is a scheduler object.Each scheduler object corresponds to an element of the physicalstructure of the supercomputer (but not necessarily vice versa), sothere is one node for the entire machine (e.g., node 100 as shown inFIG. 2), one node for each physical node of the system (e.g., node 102as shown in FIG. 2), one node for each multicore socket on the physicalnodes that comprise the entire machine (e.g., node 202 as shown in FIG.2), one node for each core of each socket (e.g., node 210 as shown inFIG. 2), and one node for each hyperthread on that core (e.g., node 232as shown in FIG. 2).

Each scheduler object s:

Is associated with a physical component (e.g., rack, blade, socket,core, hyperthread).

Except for the root of the tree, has a parent scheduler object which ispartly responsible for directing its operations (as explained in moredetail below).

Has a set of children each of which is a scheduler object. This is thenull set for a leaf (e.g., hyperthread) node. As explained in moredetail below, it is the responsibility of a scheduler object s to manageand assign (or re-assign) work to its children, and indirectly to itsgrandchildren, etc. (i.e., s manages all nodes in the subtree rooted ats).

Has a work queue, which is a set of continuations (as describedearlier).

Has a (possibly empty) set of I/O devices that it also has theresponsibility to manage and assign (or re-assign) work.

Each node can potentially be associated with a layer of some form ofcache memory. Cache hierarchy follows the hierarchy of the tree in thesense that the higher the scheduler object is, the slower it willusually be for computations to efficiently utilize caches at thecorresponding level of hierarchy. The cache of a scheduler objectcorresponding to a physical node can be a cache of memory correspondingto that node. The memory on the physical node can be thought of as acache of the memory of the virtual machine.

Resource Migration—Additional Information

The hyper-kernel simulates part of the virtual hardware on which thevirtual configuration resides. It is an event-driven architecture,fielding not only translated physical hardware events, but soft events,such as receipt of inter-node hyper-kernel messages generated byhyper-kernel code running on other nodes.

As explained above, when an interrupt event significant to thehyper-kernel occurs, the hyper-kernel makes a decision of how to respondto the interrupt. Before control is returned to the operating system,any higher priority interrupts are recognized and appropriate actionsare taken. Also as explained above, the hyper-kernel can make threeseparate decisions: (1) which resources to migrate upon certain events,(2) when to migrate them, and (3) to where those resources should move.

In the following example, suppose a scheduler object “s” in a virtualmachine is in steady state. Each scheduler object corresponding to aphysical node has a set of physical processor sockets assigned to it.Hyperthreads in these sockets may or may not be busy. The physical nodealso has some fixed amount of main memory and a set of I/O devices,including some network devices. Scheduler object s, when correspondingto a node, is also responsible for managing the networks and other I/Odevices assigned to nodes in the subtree rooted at s. The following is adescription of how resources can migrate upon either synchronous orasynchronous events.

Migrations Triggered by Synchronous Events

In the following example, suppose there exists a leaf node schedulerobject s, and virtual processor p assigned to s. Leaf node scheduleobject s is assumed to be executing an application or operating systemcode on behalf of an application. Assuming the leaf node is not in aninfinite loop, p will eventually run out of work to do (i.e., stall) forsome reason (e.g., waiting for completion of an I/O operation, pagefault, etc.). Instead of allowing p to actually stall, the hyper-kerneldecides whether to move the information about the stalled computation tosome other node, making one of that other node's processors“responsible” for the stalled continuation, or to keep the“responsibility” of the stalled computation on the node and instead movethe relevant resources to the current node.

The stall is thus handled in either of two ways: either the computationis moved to the physical node that currently has the resource, or elsethe resource is moved to the physical node that has requested theresource. Example pseudo code for the handling of a stall is providedbelow (as the “OnStall” routine) in the “EXAMPLE ROUTINES” sectionbelow.

Decisions such as how to handle a stall can be dependent on many things,such as the order of arrival of events, the state of the computationrunning on the virtual machine, the state of the caches, the load on thesystem or node, and many other things. Decisions are made dynamically,i.e., based on the best information available at any given point intime.

Recording Stalled Computations

Stalled computations are recorded in a data structure referred to as a“continuation.” A continuation has a status that can be, for example,“waiting-for-event” or “ready.” A stalled computation gets recorded as anewly created continuation with status “waiting-for-event.” Once thereason for stalling is satisfied (e.g., due to detection of the event),the status of the corresponding continuation is changed to “ready.” Eachcontinuation with status “ready” is stored in a “wait queue” of ascheduler object so that eventually it gets scheduled for execution. Incontrast, any continuation with status “waiting-for-event” will not bestored in any scheduler object's wait queue. Instead, it is stored inthe local shared memory of the physical node where the hardware eventthat stalled the corresponding computation is expected to occur, such asreceipt of a missing resource.

Additionally, the newly created continuation is associated with thestalling event that caused its creation. This mapping between (stalling)events and continuations awaiting these events permits fast dispatch ofasynchronous events (see the “handleEvent” described below). The mappingbetween continuations and events is stored in a table called “eventtable” and is kept in the shared memory of the corresponding physicalnode. Each physical node has its own event table, and an event table ofa physical node is directly addressable by every core on that physicalnode. All anticipated events recorded in an event table of a physicalnode correspond to hardware events that can occur on that physical node.The scheduler object s mapped to a physical node n represents n, and theevent table of n is associated with s. In some cases, severalcontinuations may be waiting on the same event, and so somedisambiguation may be required when the event is triggered.

Continuations are built using the “InitContinuation” routine. If adecision is made to move the computation, the remote physical nodeholding the resource will build a continuation that corresponds to thestalled computation and will store it in the remote physical node'sevent table. When that continuation resumes, the resource will beavailable. In effect, the hyper-kernel has transferred the virtualprocessor to a different node.

In the case where a decision is made to move the resource, the node thathas experienced the stall requests the transfer of the resource andbuilds a continuation using InitContinuation and stores it in the localevent table. Upon receipt of the resource, the continuation is attachedto an appropriate node in the TidalTree, and when that continuation isresumed, the resource will be generally be available and visible. Ineffect, the virtual resource has been transferred to the node thatrequested it.

Note that by placing continuations in event tables, it is guaranteedthat the processor that receives the event will quickly find the relatedcontinuations in its local event table. The reason for the stall in thecomputation will have been satisfied.

Having dealt with the stall, the virtual-processor p will in effect besuspended. In between processing the stall and finding a newcontinuation to resume, p becomes an “anonymous shadow processor,” i.e.,a processor with no identity known to the operating system. This shadowprocessor then looks for a new continuation to resume. An example ofthis is shown below in the “assignProcessor” routine described in moredetail below.

Notation

Let e be the event that stalled virtual processor p. Assume that e istriggered by local hardware of some physical node n. In particular,assume r is the resource, which caused the stalling event to occur.Resource r could be a block of memory, or an I/O operation, or a networkoperation. Assume that p is assigned to scheduler object s, whichbelongs to the subtree rooted at the scheduler object that representsphysical node n.

On-Stall

Pseudo code for an example on-stall routine is provided below in the“EXAMPLE ROUTINES” section. The migration-continuation function returnstrue if and only if processor p in node n decides that the resourceshould not move, i.e., the computation should move. This can bedetermined by a number of factors such as history and frequency ofmovement of r between nodes, the type of r, the cost of movement, thenumber of events in n's local event table waiting for r, system load,etc. For example, it may not be desirable to move a resource if there isa continuation stored in n's local event table that is waiting for it.

A variety of patterns of events that would benefit from migrationsexist. One approach to describing these patterns of events, like accessviolations, is in formal language theory. Regular (i.e., Chomsky type-3)languages can be recognized by finite state automata. In addition, usinga compact and flexible notation, a description of the events that areobserved can be made as sentences (or Chomsky sequences) in the regularlanguage, and the recognition modeled as state transitions in thecorresponding finite state automaton. When the full Chomsky sequence ofevents is seen, migration-continuation gets evaluated accordingly: ifthe finite state automaton accepts the Chomsky sequence, the conditionis met, otherwise, it is not met. The length of the minimized finitestate machine defines the amount of history that needs to be kept.

In various embodiments, all events happen locally, and the hyper-kernelon the physical node receiving the event must handle it—trulysynchronous events are not assumed to occur between physical nodes. Tocoordinate migration strategy between nodes, “messages” are used.Message “sends” are synchronous from a node's point of view, but message“receives” are asynchronous, in that a processor or shadow processor, ingeneral, does not wait for receipt of a message. When messages arrive,they are dealt with by the hyper-kernel as a virtual interrupt. In oneembodiment, the hyper-kernel will not allow a processor to resume acontinuation while there are messages waiting to be handled. Therefore,before control is transferred back to the operating system, the queue ischecked, and any messages are dealt with prior to the transfer ofcontrol back to the operating system.

For scheduler object s and continuation c, a cost function cost(s,c) canbe used to guide the search up the tree. If multiple ancestors of p havenon-empty queues, then p may not want to stop its search at the firstancestor found with a nonempty wait queue. Depending on the metrics usedin the optimizing strategy, p's choice may not only depend on thedistance between p and its chosen ancestor but on other parameters suchas length of the wait queues.

A function, find-best-within(s), can be used to return the “best-fit”continuation in a (non-empty) wait queue of a scheduler object. Examplesof parameters that can be considered include:

1. Position in the queue

2. The relationship between p and the last location recorded in thecontinuation (the closer those locations are the better it may be forreusing cache entries).

3. Performance indicators recorded in the continuations in the queue.

The cost and find-best-within functions can be customized as applicablewithin a given system.

Migrations Triggered by Asynchronous Events

Examples of asynchronous events include: receipt of a packet, completionof an I/O transfer, receipt of a resource, receipt of a messagerequesting a resource, etc. Generally, a hyper-kernel that receives anevent corresponding to a hardware device managed by the operating systemneeds to deliver a continuation associated with that event to ascheduler object s. By doing so, s will make this continuation availableto an appropriate scheduler object and then ultimately to thecomputation managed by the operating system represented by thatcontinuation. If, on the other hand, the event is the receipt of amessage from a hyper-kernel on another physical node, the hyper-kernelcan handle it directly.

To simplify explanation, in the examples described herein, an assumptionis made that there is only one continuation associated with an event.The procedures described herein can be generalized for the case wheremultiple continuations are associated with the same event, as needed.

In some embodiments, the search for a scheduler object on which to placethe continuation starts at the leaf of the tree that built thecontinuation and then proceeds upward (if the computation previouslyexecuted on this node). By doing so, the likelihood of reusing cacheentries is increased.

Handle-Event

Pseudo code for an example handle-event routine is provided below in the“EXAMPLE ROUTINES” section. The cost function, cost(s,c), is a functionthat helps determine the suitability of assigning c to scheduling objects. The cost function can depend on a variety of parameters such as thesize of the wait queues, the node traversal distance between s and theoriginal scheduling node for c (to increase the probability that cacheentries will be reused), and the history of the virtual processor, thephysical-processor, and the continuation. If the wait queues of thescheduler objects close to s already contain too many continuations,then it may take a relatively longer time until any newly addedcontinuation is scheduled for execution. Example conditions contributingto cost(s,c) are described below, and the conditions can be customizedas applicable.

Costs

Cost functions are used to evaluate options when selecting continuationsand scheduling objects. Cost functions can be expressed as the summationof a sum of weighted factors:

cost=w ₁ f ₁ ^(x) ₁ +w ₂ f ₂ ^(x) ₂ + . . . +w _(n) f _(n) ^(x) _(n),

where w_(i) indicates the importance of the corresponding factor andx_(i) indicates an exponential.

Examples of factors f_(i) are listed for each of the costs below.Weights w_(i) and exponents x_(i) can be determined in a variety ofways, such as empirically and by simulation. Initial weights andexponents can be tuned to various application needs, and can be adjustedby an administrator to increase performance. The weights can be adjustedwhile the system is active, and changing weights does not change thesemantics of the hyper-kernel, only the operational performancecharacteristics.

Examples of the factors that can be considered include:

Length of time since the last processor evacuated this scheduler object.

Height of the scheduler object in the TidalTree.

Length of the work queue.

Reservation status (i.e., it may be the case that some application hasreserved this resource for a specific reason).

Node specification (i.e., the node itself might have been taken out ofservice, or is problematic, has in some way a specialized function,etc.).

Age of the continuation in the queue.

Last physical processor to run this continuation.

Last virtual processor to run this continuation.

Node on which this continuation was last executing.

The “temperature” of the cache. (A cache is “warm” when it has entriesthat are likely to be reused. A cache is “cold” when it is unlikely tohave reusable cache entries.)

Group membership of the continuation (i.e., the continuation may be partof a computation group, each element of which has some affinity forother members of the group).

Performance Indicators (Hints) and special requirements.

EXAMPLES

“OnStall” and “assignProcessor”

FIG. 8 illustrates an embodiment of a process for selectively migratingresources. In some embodiments, process 800 is performed by ahyper-kernel, such as in conjunction with the OnStall routine. Theprocess begins at 802 when an indication is received that a core (orhyperthread included in a core, depending on whether the processor chipsupports hyperthreads) is blocked. As one example, suppose a hyperthreadreceives a request, directly or indirectly, for a resource that thehyperthread is not able to access (e.g., RAM that is located on adifferent node than the node which holds the hyperthread). When thehyperthread fails to access the resource (i.e., an access violationoccurs), an interrupt occurs, which is intercepted, caught, or otherwisereceived by the hyper-kernel at 802. In particular, the hyper-kernelreceives an indication at 802 that the hyperthread is blocked (becauseit cannot access a resource that it has been instructed to provide). Inaddition to reporting its blocked state, the hyperthread providesinformation such as the memory address it was instructed to access andwhat type of access was attempted (e.g., read, write, or modify).

At 804, the hyper-kernel determines whether the needed memory should bemoved (e.g., to the node on which the blocked hyperthread is located),or whether the requesting process should be remapped (i.e., the virtualprocessor should be transferred to a different node). The decision canbe based on a variety of factors, such as where the needed memory islocated, the temperature of the cache, the workload on the node holdingthe hyperthread, and the workload on the node holding the needed memory(e.g., overworked or underworked). In some embodiments, the workload ofa node is determined based at least in part on the average queue lengthin the TidalTree.

If the hyper-kernel determines that the memory should be moved, thehyper-kernel uses its current resource map to determine which node islikely to hold the needed memory and sends a message to that node,requesting the resource. The hyper-kernel also creates a continuationand places it in its event table. The hyperthread that was blocked at802 is thus freed to take on other work, and can be assigned to anothervirtual processor using the assignProcessor routine.

The hyper-kernel checks its message queue on a high-priority basis. Whenthe hyper-kernel receives a message from the node it contacted (i.e.,the “first contacted node”), in some embodiments, one of two responseswill be received. The response might indicate that the first contactednode has the needed resource (and provide the resource). Alternatively,the message might indicate that the contacted node no longer has theresource (e.g., because the node provided the resource to a differentnode). In the latter situation, the first contacted node will providethe identity of the node to which it sent the resource (i.e., the“second node”), and the hyper-kernel can send a second messagerequesting the resource—this time to the second node. In variousembodiments, if the second node reports to the hyper-kernel that it toono longer has the resource (e.g., has provided it to a third node), thehyper-kernel may opt to send the continuation to the third node, ratherthan continuing to request the resource. Other thresholds can be used indetermining whether to send the continuation or continuing the resource(e.g., four attempts). Further, a variety of criteria can be used indetermining whether to request the resource or send the continuation(e.g., in accordance with a cost function).

In the event the hyper-kernel determines that the continuation should betransferred (i.e., that the computation should be sent to another noderather than receiving the resource locally), the hyper-kernel providesthe remote node (i.e., the one with the needed resource) withinformation that the remote node can use to build a continuation in itsown physical address space. If the remote node (i.e., the one receivingthe continuation) has all of the resources it needs (i.e., is inpossession of the resource that caused the initial access violation),the continuation need not be placed into the remote node's event table,but can instead be placed in its TidalTree. If the remote node needsadditional resources to handle the continuation, the receivedcontinuation is placed in the remote node's event table.

FIG. 9 illustrates an embodiment of a process for performinghierarchical dynamic scheduling. In some embodiments, process 900 isperformed by a hyper-kernel, such as in conjunction with theassignProcessor routine. The process begins at 902 when an indication isreceived that a hyperthread should be assigned. Process 900 can beinvoked in multiple ways. As one example, process 900 can be invokedwhen a hyperthread is available (i.e., has no current work to do). Thiscan occur, for example, when the hyper-kernel determines (e.g., at 804)that a continuation should be made. The previously blocked hyperthreadwill become available because it is no longer responsible for handlingthe computation on which it blocked (i.e., the hyperthread becomes an“anonymous shadow processor”). As a second example, process 900 can beinvoked when a message is received (e.g., by the hyper-kernel) that apreviously unavailable resource is now available. The hyper-kernel willneed to locate a hyperthread to resume the computation that needed theresource. Note that the hyperthread that was originally blocked by thelack of a resource need not be the one that resumes the computation oncethe resource is received.

At 904, the TidalTree is searched for continuations that are ready torun, and one is selected for the hyperthread to resume. In variousembodiments, the TidalTree is searched from the leaf-level, upward, anda cost function is used to determine which continuation to assign to thehyperthread. As one example, when a hyperthread becomes available, thecontinuation that has been queued for the longest amount of time couldbe assigned. If no continuations are waiting at the leaf level, or areoutside a threshold specified by a cost function, a search will beperformed up the TidalTree (e.g., the core level, then the socket level,and then the node level) for an appropriate continuation to assign tothe hyperthread. If no appropriate continuations are found for thehyperthread to resume at the node level, the hyper-kernel for that nodecontacts the root. One typical reason for no continuations to be foundat the node level is that there is not enough work for that node to befully utilized. In some embodiments, the node or a subset of the nodecan enter an energy conserving state.

Time Sequence

For expository purposes, in the example, a “swapping” operation is usedto transfer continuations and memory, but in fact that's not necessaryin all embodiments.

FIG. 10 illustrates an example of an initial memory assignment andprocessor assignment. Specifically, region 1002 of FIG. 10 depicts ahyper-kernel's mapping between physical blocks of memory (on the lefthand side) and the current owner of the memory (the center column). Theright column shows the previous owner of the memory. As this is theinitial memory assignment, the current and last owner columns hold thesame values. Region 1004 of FIG. 10 depicts a hyper-kernel's mappingbetween system virtual processors (on the left hand side) and thephysical nodes (center column)/core numbers (right column).

Suppose virtual processor P00 makes a memory request to read location8FFFF and that the hyper-kernel decides to move one or more memoryblocks containing 8FFFF to the same node as P00 (i.e., node 0). Block8FFFF is located on node 2. Accordingly, the blocks containing 8FFFF aretransferred to node 0, and another block is swapped out (if evacuationis required and the block is valid), as shown in FIG. 11.

Next, suppose virtual processor P06 makes a memory request to readlocation 81FFF. The contents of this block have been moved (as shown inFIG. 11) to node 0. The hyper-kernel may determine that, rather thanmoving the memory again, the computation should be moved. Accordingly,virtual processor P06 is moved to node 0, and may be swapped withvirtual processor P01, as shown in FIG. 12.

Performance Information

Locks and Other Synchronizers

In various embodiments, the use of synchronization mechanisms like locksis minimal. Locks are used, for example, to insert queue and removequeue continuations on scheduler objects and to maintain the eventtable.

Code Path Lengths

In some embodiments, the (maximum) length of all code paths isdetermined through a static code analysis, resulting in estimable andbounded amounts of time spent in the hyper-kernel itself. All datastructures can be pre-allocated, for example, as indexed arrays. Thenodes of the TidalTree are determined at boot time and are invariant, asare the number of steps in their traversal. One variable lengthcomputation has to do with the length of the work queues, but even thatcan be bounded, and a worst-case estimate computed. In otherembodiments, other variable length computations are used.

Static Storage

In various embodiments, all data structures needed in the hyper-kernelare static, and determined at boot time, so there is no need for dynamicmemory allocation or garbage collection.

Physical Memory

All memory used by the hyper-kernel is physical memory, so no pagetables or virtual memory is required for its internal operations(except, e.g., to manage the virtual resources it is managing), furtherhelping the hyper-kernel to co-exist with an operating system.

Sharing Data and Maintaining Consistency

In some cases, e.g., to preserve the conceptual integrity of the virtualmachine being presented to the operating system, changes in one node'sdata structures are coordinated with corresponding ones in a differentnode. Many of the data structures described herein are “node local,” andeither will not need to move, or are constant and replicated. The datastructures that are node local are visible to and addressable by allhyperthreads on the node. Examples of data structures that are not nodelocal (and thus require coordination) include the current resource map(or portions thereof), the root of the TidalTree, and migratorycontinuations (i.e., continuations that might have to logically movefrom one node to another).

A variety of techniques can be used to maintain a sufficient degree ofconsistency. Some are synchronous and assume all changes are visible atthe same time to all nodes (i.e., “immediate consistency”). Others allowa more relaxed solution and strive for “eventual consistency.” Asmentioned above, physical nodes of an enterprise supercomputer areconnected via one or more high speed interconnects. Multiple instancesof hyper-kernels are interconnected to pass messages and resources backand forth between physical nodes.

Updating the Current Resource Map

Each physical node n starts off (e.g., at boot time) with the same copyof the physical resource map, the initial virtual resource map, and thecurrent resource map. Each node maintains its own copy of the currentresource map.

In some embodiments, each entry for resource r in the current resourcemap has the following:

1. A local lock, so that multiple hyperthreads on a physical-node cannotmodify r at the same time.

2. A node number specifying the node that currently owns the resource.

3. A count k of the number of times n has requested r since the lasttime it owned r.

4. A boolean which when set signifies that this node n wants r.

5. A boolean which when set signifies that this node has r but is in theprocess of transferring it, in which case the node number specifies thenew owner.

In some embodiments, the count k is used to deal with unbounded chasingof resources. If k exceeds a threshold, a determination is made that itis better to move the newly built continuation rather than chasing theresource around the system.

The following is an example of a mechanism for initiating migration ofresources and receiving resources. Key transactions include thefollowing:

1. Node n sends a request for resource r to n′.

2. Node n′ receives a request for resource r from n.

3. Node n′ may send a “deny” message to n under certain circumstances,otherwise it can “accept” and will send the resource r.

4. Node n will receive a “deny” message from n′ if the resource r cannotbe sent by n′ at this point in time. It may be that r is needed by n′,or it may be that r is being transferred somewhere else at the arrivalof the request. If the request is denied, it can send a “forwarding”address of the node to which it's transferring the resource. It may bethat the forwarding address is n′ itself, which is the equivalent of“try again later.” When node n receives the deny message, it can resendthe request to the node suggested by n′, often the new owner of theresource. To avoid n chasing the resource around the system, it can keeptrack of the number of attempts to get the resource, and switchesstrategy if the number of attempts exceeds a threshold.

5. Node n will receive the resource r if n′ can send the resource. Inthis case, n needs to schedule the continuation c that was awaiting r,so that c can be resumed.

TidalTree Root

In some embodiments, one physical node of the set of nodes in the systemis designated as a “master node.” This node has the responsibility atboot time for building the initial virtual resource map and other datastructures, replicating them to the other nodes, and booting theoperating system (e.g., Linux). The master node can be just like anyother node after the system is booted up, with one exception. At leastone physical node needs to store the root of the TidalTree. The masternode is one example of a place where the root can be placed. Updates tothe event queue of the TidalTree root scheduling object are handled ineach node by sending a message to the master node to perform the update.

Over time, the hyper-kernel will adapt and locality will continuallyimprove if resource access patterns of the operating system and theapplication permit.

Continuations

As explained above, physical memory addresses across all nodes are notunique. In some embodiments, the inclusion of physical memory addressesin continuations can be avoided by using partitioned integer indices todesignate important data structures in the hyper-kernel. In the event anaddresses needs to be put into a continuation, care is taken in themove, since the address is a physical address of the source, and bearsno relationship with the physical address in the destination. Moving acontinuation means copying its contents to the destination node asdiscussed above, and remapping any physical addresses from the source tothe target.

Timestamps

In some embodiments, access to a free-running counter is visible to allof the nodes. In the absence of this, free-running counters on each nodecan also be used. Counters in continuations are mapped between thesource and destination.

Handling of Disks and Persistent Flash

Where a needed resource is on disk (or persistent flash), in someembodiments, such resources are treated as having a heaviergravitational field than a resource such as RAM. Accordingly, disk/flashresources will tend to not migrate very often. Instead, continuationswill more frequently migrate to the physical nodes containing therequired persistent storage, or to buffers associated with persistentstorage, on a demand basis.

Operating System Configuration

There are many ways to configure an operating system. For servers, anassumption can be made that its operating system is configured to onlyrequire a small set of resource types from the virtual machineimplemented by the hyper-kernel: storage that includes linear blockarrays, networks, processors, memory, and internode interconnects. As aresult, the complexity of the operating system installation can bereduced.

Example Data Structures and Functions

The following section provides a list of examples of data structures andfunctions used in various embodiments.

init-continuation: Initializes a continuation when a computation isstalled.

assignProcessor: Routine that assigns a new continuation to a shadowprocessor (if possible).

on-stall(r): Stalling event occurs for resource r.

migrate-computation(computational-state,r,n): Message to requestmigration of a computational state to another node n which you hope hasresource r.

on-interrupt(i): Software interrupt i occurs.

handle-event(e): Routine executed when the hyper-kernel is called on tohandle an asynchronous event.

request-resource(r,n): Request transfer of resource r from node n.

initiate-send-resource(r,n): Start sending resource r to node n.

on-request-transfer-response(r,n,b): The requested transfer of r from nwas accepted or rejected. b is true if rejected.

on-transfer-requested (r,m): Receive a request from m for resource r.

on-resource-transferred(r,n): Ack of resource r has been received fromn.

on-receive-resource (r,n): Resource r has been received from n.

migration-continuation(r): True if and only if it is better to migrate acontinuation than move a resource.

parent(s): Returns the parent scheduler-object of scheduler object s.

cost(s,c): Used to evaluate placement of continuation c in thewait-queue of scheduler-object s.

find-best-within(s): A cost function that returns a continuation storedin the wait-queue of scheduler-object s.

conserve-energy: Enter low power mode.

resume-continuation(c): Resume the computation represented by c in theprocessor executing this function at the point.

valid(i): Boolean function that returns true if and only if interrupt iis still valid.

initialize(best-guess): Initializes cost variable best-guess.

insert-queue(s,c): Insert continuation c into the wait-queue ofscheduler-object s.

return-from-virtual-interrupt: Resume execution that was temporarilypaused due to the interrupt.

r.owner: Returns the node where resource r is local.

r.e: Resource r is awaiting this event.

e.r: This event is for resource r.

e.continuation: When this event occurs, need to resume continuation.

get-state( ): Returns processor's state.

scheduler-object(p): Returns scheduler-object currently associated withprocessor p.

on-request-transfer-response(r,m, response): Response to request oftransferring resource r from node m. Response can be either true if“rejected” or false if “accepted.”

Example Routines

The following are pseudo-code examples of routines used in variousembodiments. In the following, functions that start with “on-” areasynchronous events or messages coming in.

========================== init-continuation(computational-state)========================== /* InitContinuation by processor p awaitingresource r with hints h */ c = allocate continuation c.state =computational-state c.last = scheduler-object(p) c.state =waiting-for-event c.hints = h e = allocate event in event-tablee.resource = r e.continuation = c return c end InitContinuation========================== assignProcessor ========================== /*Once processor p in physical node n becomes a shadow processor, it givesup its O/S identity and starts looking for a continuation with which toresume execution. p will look for such a continuation in wait-queues asfollows: */ s = scheduler-object (p) initialize (best-guess) best-s =nil /* traverse upwards, keeping track of best candidate */ /* assumethere is a locally cached copy of the root */ repeat guess = cost (s) ifguess > best-guess then best-guess = guess best-s = s s = parent (s)until s = nil if best-s <> nil then c = find-best-within (best-s)resume-continuation (c) else conserve-energy end assignProcessor========================== on-stall(r) ========================== /*OnStall is invoked when the hardware detects an inconsistency betweenthe virtual and physical configurations. More specifically, node nrequests resource r which the hardware cannot find on node n. */ ifmigration-continuation (r) then /* send the computation to node n */ nn= owner(r) /* node n believes resource is probably at node nn */migrate-computation (r,nn) else /* request the resource r */ c =init-continuation(get-state( )) /* insert code here to insert c into thelocal event-table */ request-resource(r, owner(r)) assignProcessor /* Atthis point, p is an anonymous shadow processor */ /* p needs to findsome work to do */ end OnStall ==========================on-migrate-computation(computational-state, r,n)========================== /* the remote node gets the message from n toreceive a continuation. Note: c in this case is the contents of thecontinuation, not the continuation itself. */ c = InitContinuation /*with the information in the request */ c.state = computational-state e =insert c into the local event-table handle-event (e) endon-migrate-computation ========================== on-interrupt(i)========================== /*When a processor p (in subtree of physicalnode n) is interrupted by i (using a very low level mechanism specificto the particular hardware design), p does the following: */ while valid(i) e = event-table (i) /* find the event corresponding to i */handle-event (e) i = next-queued-interrupt end while /* resume priorexecution */ return-from-virtual-interrupt end on-interrupt========================== handle-event(e) ========================== /*An event occurred. Move it from the event table to the bestscheduler-object. */ c = e.continuation /* find the continuation forevent e */ event-table (i).clear = true /* remove the event from thetable */ e.complete = true /* mark e as completed */ c.state = ready /*now find out the best place to put c */ s = c.last initialize(best-guess) /* look for best choice */ /* assume there is a locallycached copy of the root */ repeat guess = cost (s,c) if guess >best-guess then best-guess = guess best-s = s s = parent (s) until s =nil insert-queue (best-s,c)/* queue up c in the wait-queue of best-s */end handle-event ========================== request-resource (r,n)========================== /* When a node n needs a resource r owned bynode n′ the resource is requested, but the request may not be satisfiedbecause someone else might have beaten you to request it or n′ iscurrently using it. */ current-resource-map(r).wanted = truerequest-transfer(owner(r),r) /* send a request to the owner of r */ /*requesting r's transfer */ return ==========================on-request-transfer-response (r, m, is-rejected)========================== /* Now, consider that you are a node gettinga response from a previous request to a node for a resource r. When theresponse to this request comes in, it can be accepted or rejected. */ ifis-rejected then /* resource has been transferred to m */ increment k ifk > threshold then /* you don't want to go chasing around forever*/ /*trying to get the resource. Give up */ migrate-computation(r,m) returnelse request-transfer(r,m) /* try again */ return else /* request wasnot rejected and r is the resource */ r.k = 0 r.wanted = false /*resource has been moved */ r.owner = me /* set the owner to n (i.e.,“me”) */ if the resource is memory, update the hardware memory map withthe new memory return ========================== on-transfer-requested(r,n) ========================== /* When a resource request for r comesfrom node n, if transfer in progress to owner(r), deny the request */ ifr.being-transferred then send-request-response (r, owner(r), true) else/* transfer of resource is accepted */ r.transferring = trueinitiate-send-resource(r) if type(r) = memory then update local memorymap send-request-response (r, owner(r), false) return========================== on-resource-transferred (r,n)========================== /* When an acknowledgement comes in that thetransfer is complete */ r.owner = n r.transferring = false return========================== on-receive-resource(r,n)========================== /* Now we receive a message with therequested resource r from n*/ r.k = 0 r.wanted = false/* clear the bitsaying that it's wanted */ r.owner = me /* set the owner to n (i.e.,“me”) */ if the resource is memory, update the memory map with the newmemory send-resource-transferred(r,n) handle-event(r.e) /* the eventwe've been waiting for has occurred */ return

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. (canceled)
 2. A computer system, comprising: oneor more I/O devices; physical memory; and a plurality of physical nodes,wherein an operating system is run collectively across the plurality ofphysical nodes; wherein each physical node includes one or more physicalprocessors, and wherein each physical processor has one or more cores,and wherein each core has one or more hyperthreads; wherein each core orhyperthread instantiates one or more virtual processors, wherein avirtual processor comprises a computing engine visible to the operatingsystem run collectively across the plurality of physical nodes; whereineach core or hyperthread is configured to invoke a hyper-kernel on itshosting physical processor when the core or hyperthread cannot access aresource needed by the core or hyperthread, the needed resourcecomprising at least one of: (1) a portion of the physical memory neededby the core or hyperthread, and (2) an I/O resource needed by the coreor hyperthread; and wherein the hyper-kernel remaps the virtualprocessor to another core or hyperthread that can access the neededresource.
 3. The computer system of claim 2 wherein remapping thevirtual processor comprises transferring a continuation to a remotenode, wherein the continuation comprises a representation of a state ofthe virtual processor.
 4. The computer system of claim 3 wherein thehyper-kernel provides the remote node with information usable to buildthe continuation.
 5. The computer system of claim 3 wherein when theremote node is in possession of the needed resource, the continuation isplaced in a hierarchical data structure usable to schedule execution ofthe continuation.
 6. The computer system of claim 3 wherein when theremote node needs additional resources to handle the continuation, thecontinuation is placed in an event table local to the remote node.
 7. Amethod, comprising: receiving, at a hyper-kernel on a hosting physicalprocessor, an indication that a core or hyperthread which instantiatesone or more virtual processors cannot access a resource needed by thecore or hyperthread, the needed resource comprising at least one of: (1)a portion of a physical memory needed by the core or hyperthread, and(2) an I/O resource needed by the core or hyperthread; and remapping, bythe hyper-kernel, the virtual processor to another core or hyperthreadthat can access the needed resource.
 8. The method of claim 7 whereinremapping the virtual processor comprises transferring a continuation toa remote node, wherein the continuation comprises a representation of astate of the virtual processor.
 9. The method of claim 8 wherein thehyper-kernel provides the remote node with information usable to buildthe continuation.
 10. The method of claim 8 wherein when the remote nodeis in possession of the needed resource, the continuation is placed in ahierarchical data structure usable to schedule execution of thecontinuation.
 11. The method of claim 8 wherein when the remote nodeneeds additional resources to handle the continuation, the continuationis placed in an event table local to the remote node.
 12. A computersystem, comprising: one or more I/O devices; physical memory; and aplurality of physical nodes, wherein an operating system is runcollectively across the plurality of physical nodes; wherein eachphysical node includes one or more physical processors, and wherein eachphysical processor has one or more cores, and wherein each core has oneor more hyperthreads; wherein each core or hyperthread instantiates oneor more virtual processors, wherein a virtual processor comprises acomputing engine visible to the operating system run collectively acrossthe plurality of physical nodes; wherein each core or hyperthread isconfigured to invoke a hyper-kernel on its hosting physical processorwhen the core or hyperthread cannot access a resource needed by the coreor hyperthread, the needed resource comprising at least one of: (1) aportion of the physical memory needed by the core or hyperthread, and(2) an I/O resource needed by the core or hyperthread; and wherein thehyper-kernel moves the needed resource to a location accessible by thehosting physical processor.
 13. The computer system of claim 12 whereinthe hyper-kernel requests the needed resource at least in part bysending a message to a remote node.
 14. The computer system of claim 13wherein the hyper-kernel determines the remote node based at least inpart on a resource map.
 15. The computer system of claim 12 wherein thehyper-kernel generates a continuation, and wherein the continuationcomprises a representation of the virtual processor.
 16. The computersystem of claim 15 wherein the hyper-kernel places the continuation inan event table.
 17. A method, comprising: receiving, at a hyper-kernelon a hosting physical processor, an indication that a core orhyperthread which instantiates one or more virtual processors cannotaccess a resource needed by the core or hyperthread, the needed resourcecomprising at least one of: (1) a portion of a physical memory needed bythe core or hyperthread, and (2) an I/O resource needed by the core orhyperthread; and moving, by the hyper-kernel, the needed resource to alocation accessible by the hosting physical processor.
 18. The method ofclaim 17 wherein the hyper-kernel requests the needed resource at leastin part by sending a message to a remote node.
 19. The method of claim18 wherein the hyper-kernel determines the remote node based at least inpart on a resource map.
 20. The method of claim 17 wherein thehyper-kernel generates a continuation, and wherein the continuationcomprises a representation of the virtual processor.
 21. The method ofclaim 20 wherein the hyper-kernel places the continuation in an eventtable.